Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-090

Text File | 1995-12-31 | 96KB | 2,590 lines

C.S.M.P. Digest             Fri, 24 Mar 95       Volume 3 : Issue 90

Today's Topics:

        CW5, ansi C, and 68k vs. PPC vs. SG
        Copybits trouble.
        NEWBIE: Saving Popup Menu Selection
        Recommend: A better List Mgr.
        Resources and header files
        Temporary Memory question...
        The State of MPW
        [Q] FSSpec --> dirID



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Peter Figliozzi)
Subject: CW5, ansi C, and 68k vs. PPC vs. SG
Date: Sun, 26 Feb 1995 17:19:29 -0500
Organization: Indiana U. Dept. of Physics


This weekend I whipped up a little program that just does a big
computation; it's ANSI C.  I compiled it with CW5 for my PPC 6100/60, for
68k (ran on the same PPC under emulation), and then popped in on the
Silicon Graphics Indigo I use at work.

Here are the results:

PPC w/ 68k emulation          240 sec.
PPC 6100/60 native             40 sec.
Indigo                          6 sec.


First, I am very impressed with CW5 because I didn't have to edit one
stinkin' line of code to get it to run on the Indigo!  Even the compiler
warnings were the same!!

My question is (and it might be a little nitpicky): I'm supposed to be
about 10x faster with floating point stuff with native PPC than 68k,
right??  As you can see I only get about 6x speedup.

I must be doing something with the compiler options or inefficient code.
Playing with the compiler options, adding register variables, and making
functions inline produced no noticeable effect.  Maybe someone can give me
some comments?  I tacked the code onto the end of this message.  Here's
what it does:

[We've got 125 atoms in a lattice and we add up their potential
energies.   That's a lot of computations, since the energy must be
computed for each pair of atoms.. that's "125 choose 2" or 15,500
interactions.  This big calculation is repeated for 100 different
interaction strengths.  (Side note: don't worry about the fact that the
WrapDistance routine has three parameters that aren't used yet.  They will
be soon! )  ]

Thanks!!


/*

Calculates the energy of a particles in a cubic lattice at T=0 (potential
energy only).
Particles obey a 1/r^12 - 1/r^6 potential.

The computation is performed for different densities.


*/

////////////////////////////////////////////////////////////////////////////////////////////
// globals
////////////////////////////////////////////////////////////////////////////////////////////

#include <stdio.h>
#include <math.h>

typedef struct
{
   int x;
   int y;        // holds coordinates of a particle
   int z;

} tuple;

// size of the lattice :

#define  L_x   5
#define  L_y   5
#define  L_z   5

#define     num_particles  L_x * L_y * L_z


float Potential(float sigma_over_r);
float WrapDistance( tuple *particle1, tuple *particle2,
                     int x_length, int y_length, int z_length);
float FindEnergy(float sigma /* range of potential */);
void  BuildParticleTable(void);


tuple particle[ num_particles + 1];  // +1 so we can count from 1 instead
of zero



////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////

void main(void)
{
float energy;
float sigma;

int n;

    printf("\n");

    BuildParticleTable();

    for (n=0; n<100; n++)
    {
      sigma = 0.01 + n*.05;
      energy = FindEnergy(sigma);

      printf("Sigma: %4.2f   Energy: %6.2f \n",sigma,energy);
   };

}

////////////////////////////////////////////////////////////////////////////////////////////

void BuildParticleTable(void)
{


int i,j,k,n;

//
// first build a lookup table of particles, called "particle"
//

n=1;

   for (i=1; i <= L_x; i++)
   {
      for (j=1; j <= L_y; j++)
      {
         for (k=1; k<= L_z; k++)

         {
            particle[n].x = i;
            particle[n].y = j;
            particle[n].z = k;

            n++;
         };
      };

   };

}

////////////////////////////////////////////////////////////////////////////////////////////

float FindEnergy(float sigma /* range of potential */)
{


int n,m; // for looping

float distance;
float scaled_inv_distance;
float energy = 0;


// now add up pair interactions, using the particle lookup table
// to avoid overcounting

   for (n=1; n < num_particles; n++)
   {
      for (m=n+1; m <= num_particles; m++)
      {


            distance = WrapDistance ( &(particle[n]),
                                      &(particle[m]),
                                           0,0,0);

            scaled_inv_distance = sigma * (1/distance);

            energy += Potential(scaled_inv_distance);
      }
   }

   return energy;
}

////////////////////////////////////////////////////////////////////////////////////////////

float Potential(float sigma_over_r)
{
#define  epsilon  1  // scale factor

float to_the_sixth;

   // to speed things up a bit, DON'T CALL pow(x,y) for x^y.
   // Multiplication is MUCH faster

   to_the_sixth =
sigma_over_r*sigma_over_r*sigma_over_r*sigma_over_r*sigma_over_r*sigma_over_r;

   return 4*epsilon*( to_the_sixth*to_the_sixth - to_the_sixth );

}

////////////////////////////////////////////////////////////////////////////////////////////

// WrapDistance
//
// calculates the reduced r known as [r_ij] ("video game boundary conditions")
// edge effects are reduced (hopefully)
//
// particle coordinates are (i1,j1,k1)  (i2,j2,k2)
//


float WrapDistance( tuple *particle1, tuple *particle2,
                     int x_length, int y_length, int z_length)
{
float dist_sqr;

float dx, dy, dz;

    dx = particle1->x - particle2->x;
    dy = particle1->y - particle2->y;
    dz = particle1->z - particle2->z;

   dist_sqr = dx*dx + dy*dy +dz*dz;

   return pow(dist_sqr,0.5);
}
--

// Pete Figliozzi
// [e-mail]
// phone: [phone]
// fax:   [phone]

+++++++++++++++++++++++++++

>From [e-mail] (MegaWatt)
Date: Mon, 27 Feb 1995 16:42:36 GMT
Organization: University of Chicago

In article <[e-mail]>,
[e-mail] (Peter Figliozzi) wrote:

>This weekend I whipped up a little program that just does a big
>computation; it's ANSI C.  I compiled it with CW5 for my PPC 6100/60, for
>68k (ran on the same PPC under emulation), and then popped in on the
>Silicon Graphics Indigo I use at work.
>
>Here are the results:
>
>PPC w/ 68k emulation          240 sec.
>PPC 6100/60 native             40 sec.
>Indigo                          6 sec.

[ rest deleted ]


Try changing all of your int variables to float. Merely using floats
instead of ints whenever you can will increase execution speed. (this is
especially useful for loop control variables)

- --------------------------------------------------------------------
  MegaWatt                         |
                                   |    _____  _____  _____   _   _
  - AKA -                          |   |__  / | ___ || ___ \ | | | |
                                   |     / /  | |_| || |_/ / | | | |
  Aaron L. Bratcher                |    / /__ | ___ ||  __/  |_| |_|
  University of Chicago            |   |_____||_| |_||_|     (_) (_)
  [e-mail]  |
- --------------------------------------------------------------------

"I think it's a good thing Bill Gates is getting married, because then
he may find out there's more to life than working on computers!!"
-- Richard Finkelstein, President, Chicago based Performance Computing

+++++++++++++++++++++++++++

>From [e-mail] (Tom Andersen)
Date: 27 Feb 1995 17:06:09 GMT
Organization: University of Guelph

Peter, You are missing the new faster Mathlib.

It is on the Code warrior disks.

Install it and your timing will be as follows:
>This weekend I whipped up a little program that just does a big
>computation; it's ANSI C.  I compiled it with CW5 for my PPC 6100/60, for
>68k (ran on the same PPC under emulation), and then popped in on the
>Silicon Graphics Indigo I use at work.

>Here are the results:

>PPC w/ 68k emulation          240 sec.
>PPC 6100/60 native             40 sec.
>Indigo                          6 sec.
PowerMac with New mathlib       6.13 sec
With one change to source:      4.05 sec
with some samll changes plus
turn optimizer on full          2.65 secs

Tom Andersen

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Geweke)
Date: Mon, 27 Feb 1995 12:20:58 -0600
Organization: Michigan State University

In article <[e-mail]>,
[e-mail] (MegaWatt) writes:
> Try changing all of your int variables to float. Merely using
> floats instead of ints whenever you can will increase execution
> speed. (this is especially useful for loop control variables)

Bzzzt. Wrong answer. This _sometimes_ works; however, if his computations are
all done using FP, he'll often be better off using ints as loop control
variables.

The reason people say what you said is because quite often loops are doing
_only_ integer computations. The 601, 603, 604, and 620 all have at least one
FP pipe and one integer pipe. So, if your loop is doing integer calcs and your
loop control variable is integer, you're not getting any use out of the FP
pipe. If you make your control variable a FP variable, it'll use that extra
pipe and will run "in parallel" to some degree. It'll speed things up.

But if all his calcs (or at least some of them) are done in FP inside the
loop, it'll slow things down, instead. He'll be better off using an integer
loop counter.

                                                        / ag


- -------------------------------------------------------------------------
Andrew Geweke / Michigan State / http://www.cps.msu.edu/~gewekean/home.html








+++++++++++++++++++++++++++

>From [e-mail] (Willie Abrams)
Date: Mon, 27 Feb 1995 09:59:00 -0600
Organization: OUHSC Telemedicine

In article <[e-mail]>,
[e-mail] (Peter Figliozzi) wrote:

> This weekend I whipped up a little program that just does a big
> computation; it's ANSI C.  I compiled it with CW5 for my PPC 6100/60, for
> 68k (ran on the same PPC under emulation), and then popped in on the
> Silicon Graphics Indigo I use at work.
>
> Here are the results:
>
> PPC w/ 68k emulation          240 sec.
> PPC 6100/60 native             40 sec.
> Indigo                          6 sec.

Ugh. I was a bit frightened by your results - the PowerMac should have
been as fast (if not faster than the stinkin' SGI) - so I went back and
started though your code and popped it into my copy of CW5.

First, anytime SIOUX (the ANSI console in MW) gets mixed in, you are
preparing yourself for a slowdown. Any kind of standard I/O is going to
have to grope things into the right format - either lump all of the
printfs together into blocks, write your own I/O routines, or write the
results after the calculations are done.

Next, get a hold of the Balance of Power articles by Dave Evans from
develop - they have some nice techniques for writing code that uses the
RISC architecture to its advantage. (It might speed up your Indigo
execution times as well.) Unrolling some of your loops could increase your
preformance - I didn't have time to rewrite the code...

Third, use one of the new versions of the Apple MathLib. This will flat
out explode your performance. Look on your CW5 CD for details - I used the
MathLib v2 to get the best performance out of your code. I compared the
output (BBEdit of course), and there was no numerical difference in the
output values.

(Note: 60 ticks to a second...)

PowerMac 8100/80

Printf, No Opt, Rom MathLib, Time Elapsed (in Ticks): 1866 (~31 sec.)
No Printf, No Opt, Rom MathLib,Time Elapsed (in Ticks): 1429 (~24 sec.)
No Printf, Full Opt, Rom MathLib, Time Elapsed (in Ticks): 1398 (~23 sec.)

Printf, Full Opt, MathLib v2, Time Elapsed (in Ticks): 634 (~11 sec.)
No Printf, No Opt, MathLib v2,Time Elapsed (in Ticks): 262 (~4.3 sec.)
No Printf, Full Opt, MathLib v2,Time Elapsed (in Ticks): 238 (~4 sec.)

As Keith Olbermann would say, "BANG!"

Now, how much does an Indigo cost? :-)

> // Pete Figliozzi
> // [e-mail]
> // phone: [phone]
> // fax:   [phone]

W.

--
Willie Abrams, [e-mail]

"...I'm tired and have little patience for ROM-headed Unix weenies right now..."
-Chuck Shotton

+++++++++++++++++++++++++++

>From [e-mail] (David Plumpton)
Date: Tue, 28 Feb 1995 09:05:16 +1100
Organization: BNR Australia

Why does the new math library make such a large difference? As far as I can
tell from the source, the only floating point library call is for the pow()
to do that square root. Everything else is just +, -, *, and /.
Is there really that much time consumed by the one routine?

--
David Plumpton              Nobody wants my opinions
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Florian -FDj- Dejako)
Date: Tue, 28 Feb 1995 01:31:31 +0100
Organization: None. None at all!

In article <3it0q1$[e-mail]>, [e-mail] (Tom
Andersen) wrote:

> Peter, You are missing the new faster Mathlib.
> It is on the Code warrior disks.
> Install it and your timing will be as follows:

> >Here are the results:
>
> >PPC w/ 68k emulation          240 sec.
> >PPC 6100/60 native             40 sec.
> >Indigo                          6 sec.
> PowerMac with New mathlib       6.13 sec
> With one change to source:      4.05 sec
> with some samll changes plus
> turn optimizer on full          2.65 secs
>
> Tom Andersen

Amazing!

FDj

--
____________________________________________________________________
Florian Dejako                           Student of Computer Science
[e-mail]                                  and Macintosh Fanatic

+++++++++++++++++++++++++++

>From [e-mail] (Tom Andersen)
Date: 28 Feb 1995 21:54:39 GMT
Organization: University of Guelph

David Plumpton ([e-mail]) wrote:
: Why does the new math library make such a large difference? As far as I can
: tell from the source, the only floating point library call is for the pow()
: to do that square root. Everything else is just +, -, *, and /.
: Is there really that much time consumed by the one routine?

: --
: David Plumpton              Nobody wants my opinions
: [e-mail]

David,

The old ROM version of Mathlib typically does 20k floating pints per
second (sin, exp, sqrt, etc).

The new one is TWENTY TIMES faster!!

So yes in the original post >95% of the time was spent in the one call to
pow(x, 0.5) !

even with the fast mathlib it still well over 50%.

Tom Andersen

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Thu, 2 Mar 1995 11:17:59 +1300 (NZDT)
Organization: (none)

[e-mail] (Peter Figliozzi) writes:
> This weekend I whipped up a little program that just does a big
> computation; it's ANSI C.  I compiled it with CW5 for my PPC 6100/60, for
> 68k (ran on the same PPC under emulation), and then popped in on the
> Silicon Graphics Indigo I use at work.
>
> Here are the results:
>
> PPC w/ 68k emulation          240 sec.
> PPC 6100/60 native             40 sec.
> Indigo                          6 sec.

Changing the line...

   return pow(dist_sqr,0.5);

... to ...

   return sqrt(dist_sqr);

... cut it down from 35 seconds to 9 seconds on my 6100/60.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Brent S. Stone)
Date: Sat, 4 Mar 1995 04:53:03 GMT
Organization: University of Virginia

In article <plumpto-2802950905160001@47.181.192.81>,
David Plumpton <[e-mail]> wrote:
>Why does the new math library make such a large difference? As far as I can
>tell from the source, the only floating point library call is for the pow()
>to do that square root. Everything else is just +, -, *, and /.
>Is there really that much time consumed by the one routine?
>
little side info-
I timed 50 million iterations of the pow and sqrt functions
and got:
pow  433 sec
sqrt 116 sec

pow is pitiful for any simple exponents.
To get a^3.5  you're better off doing a*a*sqrt(a)

fmod was the worst function I looked at by far.
acos, asin, pow are in the same ballpark execution timewise.

I would have thought the ppc would have had instructions for
floor, ceil and round but its not the case.



+++++++++++++++++++++++++++

>From Andreas Franz <[e-mail]>
Date: Sun, 05 Mar 95 22:46:19 +0100 (MEZ)
Organization: (none)


In article <[e-mail]>, Peter
Figliozzi writes:

>
>
> This weekend I whipped up a little program that just does a big
> computation; it's ANSI C.  I compiled it with CW5 for my PPC 6100/60,
for
> 68k (ran on the same PPC under emulation), and then popped in on the
> Silicon Graphics Indigo I use at work.
>
> Here are the results:
>
> PPC w/ 68k emulation          240 sec.
> PPC 6100/60 native             40 sec.
> Indigo                          6 sec.
>
>
> First, I am very impressed with CW5 because I didn't have to edit one
> stinkin' line of code to get it to run on the Indigo!  Even the compiler
> warnings were the same!!
>
> My question is (and it might be a little nitpicky): I'm supposed to be
> about 10x faster with floating point stuff with native PPC than 68k,
> right??  As you can see I only get about 6x speedup.
>
> I must be doing something with the compiler options or inefficient code.

> Playing with the compiler options, adding register variables, and making
> functions inline produced no noticeable effect.  Maybe someone can give
me
> some comments?  I tacked the code onto the end of this message.  Here's
> what it does:
You did right. I got 34 seconds on my 7100/66

The problem is the function "pow". It's done by software and slowwwwww.
The fpu found in the ppc 601 is very fast. But it has no sin, tan, pow,
sqrt, .......... All those functions are done by the mathlib, found in rom
or, as a faster version, in your extensions-folder.

hope this helps
Andreas
--
What do you get when you cross a parrot with a centipede?
You'll get a walkie-talkie ;-)))
  The best way to accelerate a PC is 9.8 m/s^2

---------------------------

>From [e-mail] (Ernie Soffronoff)
Subject: Copybits trouble.
Date: 3 Mar 1995 15:50:02 GMT
Organization: StarNet Communications, Inc

Howdy,

In an effort to be cool, I decided to try some off-screen graphics a la
NIM: Imaging with Quickdraw.  The result: I'm not cool.  I get a type
mismatch on the copybits line of the code below.  The rest of it seems
okay, allocating memory and such and not crashing.  What the heck is
copybits expecting?  (And why the heck is NIM in Pascal?)

(And if you feel like commenting on anything else, go ahead.)

(I took out some error checking to make the code shorter.)

--Ernie

static void DoDrawQuick(void)
{

        CGrafPtr                origPort;
        GDHandle                origDev;
        QDErr                   myErr;
        GWorldPtr               myOffGWorld;
        PixMapHandle            offPixMapHandle;
        short                   good;
        Rect                    sourceRect, destRect;
        GWorldFlags             flags = nil;

        PixMapHandle    pmh;

        GetGWorld(&origPort,&origDev);
        myErr = NewGWorld(&myOffGWorld, 0, &(curWindow->portRect), nil, nil, 0);
        SetGWorld(myOffGWorld, nil);
        offPixMapHandle = GetGWorldPixMap(myOffGWorld);
        good = LockPixels(offPixMapHandle);
        EraseRect(&(myOffGWorld->portRect));

        //Do some drawing here

        SetGWorld(origPort, origDev);
        sourceRect = myOffGWorld->portRect;
        sourceRect.bottom = myOffGWorld->portRect.bottom - 15;
        sourceRect.right = myOffGWorld->portRect.right - 15;
        destRect = curWindow->portRect;
        destRect.bottom = curWindow->portRect.bottom - 15;
        destRect.right = curWindow->portRect.right - 15;

        pmh = myOffGWorld->portPixMap;

        CopyBits(*pmh, GrafPtr(curWindow)->portBits, sourceRect,
                        destRect, srcCopy, nil);

        UnlockPixels(offPixMapHandle);
        DisposeGWorld(myOffGWorld);
}


+++++++++++++++++++++++++++

>From [e-mail] (LearnTV)
Date: 3 Mar 1995 11:43:21 -0500
Organization: America Online, Inc. (1-800-827-6364)

> pmh = myOffGWorld->portPixMap;
>
> CopyBits(*pmh, GrafPtr(curWindow)->portBits, sourceRect,
>   destRect, srcCopy, nil);

Your problem with this statement is how you are casting
curWindow.  The above is Pascal syntax.  It should be:

pmh = GetGWorldPixMap(myOffGWorld);

CopyBits((BitMap *) (*pmh),
   &curWindow->portBits,
   &sourceRect,
   &destRect,
   srcCopy,
   nil);

You need to look at the c header files to know what
they are looking for.  Rectangles can only be passed
by address in C, for example.

Good Luck!

Greg Bolsinga
Learn Television


+++++++++++++++++++++++++++

>From [e-mail] (Ernie Soffronoff)
Date: 3 Mar 1995 18:54:33 GMT
Organization: StarNet Communications, Inc

Oh, and I should say that the type mismatch appears in the first argument
to copybits.

--Ernie

+++++++++++++++++++++++++++

>From [e-mail] (Stephen &roo Sample)
Date: 3 Mar 1995 21:14:47 GMT
Organization: RadioVcular Stereo Systems

In article <3j7dra$[e-mail]>, [e-mail] (Ernie
Soffronoff) wrote:

>         CopyBits(*pmh, GrafPtr(curWindow)->portBits, sourceRect,
>                         destRect, srcCopy, nil);

CopyBits wants its first two arguments to look like pointers to bitmaps, so try

   CopyBits((BitMap *)*pmh, &curWindow->portBits,
         sourceRect, destRect, srcCopy, nil)


Ta,
   -Stephen

+++++++++++++++++++++++++++

>From [e-mail] (Stephen &roo Sample)
Date: 3 Mar 1995 21:18:55 GMT
Organization: RadioVcular Stereo Systems

Oh, and I forgot, if the system has 32-bit QD 1.3 or later, you should use

         pmh = GetGWorldPixMap(myOffGWorld);

rather than

>         pmh = myOffGWorld->portPixMap;


Ta,
   -Stephen

+++++++++++++++++++++++++++

>From [e-mail] (Jochen Lippert)
Date: Sun, 05 Mar 1995 19:01:23 +0100
Organization: University of Bremen

In article <3j7dra$[e-mail]>, [e-mail] (Ernie
Soffronoff) wrote:

> Howdy,
>
> In an effort to be cool, I decided to try some off-screen graphics a la
> NIM: Imaging with Quickdraw.  The result: I'm not cool.  I get a type
> mismatch on the copybits line of the code below.  The rest of it seems
> okay, allocating memory and such and not crashing.  What the heck is
> copybits expecting?  (And why the heck is NIM in Pascal?)
>
(some code deleted)
>
>         CopyBits(*pmh, GrafPtr(curWindow)->portBits, sourceRect,
>                         destRect, srcCopy, nil);
>
I think the reason why your compiler complains is the second parameter of
the CopyBits call. It should be: (GrafPtr)curWindow->portBits. The problem
really seems to be that NIM's code examples are in Pascal, cause you used
a Pascal style type conversion here (can be quite confusing reading Pascal
and writing C).

Jochen Lippert

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jochen Lippert)
Date: Mon, 06 Mar 1995 12:47:51 +0100
Organization: University of Bremen

In article <[e-mail]>,
[e-mail] (Jochen Lippert) wrote:

(The piece of C code that caused the trouble:)

>
>         CopyBits(*pmh, GrafPtr(curWindow)->portBits, sourceRect,
>                         destRect, srcCopy, nil);
>

Oops! Greg Bolsinga discovered some more errors, and he is right: CopyBits
wants the BitMaps and the Rects as pointers, so you must pass their
addresses. Apart from that, it doesn't seem to be neccessary to convert
the WindowPtr to a GrafPtr, although that may be good style... ;)

Jochen Lippert

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ernie Soffronoff)
Date: 7 Mar 1995 15:36:41 GMT
Organization: StarNet Communications, Inc

Thanks to all who replied here and via mail!  I've got it working now.
Though I got mail about not posting this to csmp.codewarrior, posting it
here got a lot more responses than csmp.help.  That doesn't make it right
(since it certainly wasn't a CodeWarrior problem but a C/Toolbox problem),
and I won't do it again, but I think it says a lot about CW users.

Will NIM be changed into C?  For a somewhat new and incompletely trained
C programmer who still thinks in Pascal part of the time, I find it a
real drag.

--Ernie
[e-mail]

---------------------------

>From [e-mail] (John Kloss)
Subject: NEWBIE: Saving Popup Menu Selection
Date: Thu, 09 Mar 1995 19:19:22 -0500
Organization: Bristol-Myers Squibb

As a fledgling C programmer, I am at the point where I am just starting to
be able to get myself into trouble, but lack the expertise to get myself
back out again.  My situation is this.  I have created a (modal) dialog
box which contains the usual assortment of nefarious suspects (popup menu,
save/cancel buttons, editable text items, and static text items).
Operationally, the popup menu is used to control which static and editable
text items are visible.  I have been able to write the editable text items
into a 'STR ' resource so that I can read them back when necessary.  My
problem is that I am not quite sure how to save and restore the popup menu
setting.  I assume that I can write the menu item to an 'STR ' resource
and then, whenever I need to, I can retrieve the 'STR ' string, turn it
back into a number, and then drop the number into an "Adjust_PopUp_Menu(
)" routine.  Is there a better way?  I am not even sure that this approach
will work, and am even less certain as to what would go into the
"Adjust_PopUp_Menu( )" routine.
As an addendum, I should add that I have not, as yet, learned "Files" so
reading/writing into a prefs file it out (for now).  Anyway, the main
problem of restoring a popup menu to a pre-existing setting would still
remain.
Any direction or source code tidbits would be greatly appreciated.
Thanks,
John

--
John Kloss
[e-mail]
[phone] 609-252-5284  [fax] 609-252-6094
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 10 Mar 1995 01:58:38 GMT
Organization: University of Pennsylvania, Linguistics Department

In article <[e-mail]>,
John Kloss <[e-mail]> wrote:
>As a fledgling C programmer, I am at the point where I am just starting to
>be able to get myself into trouble, but lack the expertise to get myself
>back out again.  My situation is this.  I have created a (modal) dialog
>box which contains the usual assortment of nefarious suspects (popup menu,
>save/cancel buttons, editable text items, and static text items).
>Operationally, the popup menu is used to control which static and editable
>text items are visible.  I have been able to write the editable text items
>into a 'STR ' resource so that I can read them back when necessary.  My
>problem is that I am not quite sure how to save and restore the popup menu
>setting.  I assume that I can write the menu item to an 'STR ' resource
>and then, whenever I need to, I can retrieve the 'STR ' string, turn it
>back into a number, and then drop the number into an "Adjust_PopUp_Menu(
>)" routine.  Is there a better way?  I am not even sure that this approach
>will work, and am even less certain as to what would go into the
>"Adjust_PopUp_Menu( )" routine.

Since you already know how to write into resources, why don't you just save
the number for your popup menu item in its own little resource?  I don't
know C, but here's how I'd do this in Pascal:

type
  IntPtr = ^Integer;
  IntHandle = ^IntPtr;  {to get around the type restrictions}
var
  OkSoFar : Boolean;    {If anything goes wrong, we set this to FALSE.}
  MyIntHandle : IntHandle;  {Handle to the new resource.}
begin
  OkSoFar := TRUE;   {So far, we've encountered no errors.}

> MyIntHandle := IntHandle(NewHandle(SizeOf(Integer)));  {Create a handle.}
  if MemErr <> 0 then    {Did it go okay?}
    OkSoFar := FALSE;    {No, so fall through the rest of the routine.}

  if OkSoFar then    {No errors so far, so let's continue.}
     begin
       MyIntHandle^^ := MyPopupNumber;  {Store the value in the handle.}
>      AddResource (Handle(MyIntHandle), 'Blah', 128, '');
              {Add the handle as a resource.}
              {Maybe these arguments aren't in the right order}
              {'Blah' is the resource type; 128 is the rsrc number}
       if ResErr <> 0 then   {Did everything go okay?}
          OkSoFar := FALSE;  {No, so fail.}
     end;

I've put a > by the really important lines; the rest is error checking
stuff.  Then, when you start your program up again and want to read this
back in, you would call GetResource.

>As an addendum, I should add that I have not, as yet, learned "Files" so
>reading/writing into a prefs file it out (for now).  Anyway, the main
>problem of restoring a popup menu to a pre-existing setting would still
>remain.

My thinking on this general kind of issue is as follows.  Ultimately, your
program is only concerned with two things: 1) how your program stores its
data on the inside, and 2) how it represents those data to the user.
Really, programming is almost completely the clerical task of mapping back
and forth between those two representations.

If I were you, I wouldn't ask "How can I store and retrieve the setting for
a popup menu?"  Then correct question, IMHO, is "How do I store and
retrieve this underlying piece of data (which, as an irrelevant detail, I
happen to represent with a popup menu)?"  There's really two steps: 1) how
to store this value to disk, and retrieve it, and 2) how to map the value
to a popup menu representation, and how to map user actions on that popup
back into the value.

      Disk  <--------->   Variable    <----------->  User Interface Items

If you're using the Popup control items (which I guess most people do these
days), it's a little misleading, since that control holds the number of the
currently visible item.  It's up to you whether you want to use this as the
place where you keep track of your data.  Personally, I keep all my data in
underlying data structures which the user never sees; I never keep data
only in controls.  The fact that some controls hold a value is to me a
trivial detail in the process of representing the underlying data to the
user.  But that's personal style.

I hope all this hasn't been too far out in left field.

  \/ __ __    _\_     --Sean Crist  ([e-mail])
 ---  |  |    \ /     For a free copy of the Bill of Rights, finger
  _| ,| ,|   -----       this account.
  _| ,| ,|    [_]     Q: What do Standard Oil, AT&T, and Microsoft have in
   |  |  |    [_]        common?   A:  Nothing... yet.

---------------------------

>From [e-mail] (Sergio Nakai)
Subject: Recommend: A better List Mgr.
Date: 7 Mar 1995 21:43:29 GMT
Organization: Oracle Corporation. Redwood Shores, CA


I'm looking for a better and more powerful table/list manager than
the Mac Toolbox's List Manager.  I found adds for 2 products--
StoneTablet Publishing's Stone Table 2.0 and Graphical Business
Interfaces, Inc.'s TableIt!  Does anybody have any comments, praises,
concerns, etc. with either of these products or companies (quality of
products, ease of use, look and feel of tables, support, bug fixes,
etc)?  Or, is there a better product available?  Any help and
information will be greatly appreciated.  Please post replies to
the c.s.m.p.help or tools newsgroups, or email directly to
[e-mail].  Thanks.

Sergio Nakai



+++++++++++++++++++++++++++

>From [e-mail] (Mickey Mestel)
Date: Thu, 9 Mar 1995 07:05:39 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Sergio,

> I'm looking for a better and more powerful table/list manager than
> the Mac Toolbox's List Manager.  I found adds for 2 products--
> StoneTablet Publishing's Stone Table 2.0 and Graphical Business

        i have been developing a product that needed a much more robust tool
than the list manager, and bought stone table.  unfortunately, this is a biased
review as i have never played with tabelit!

        basically, stone table is great.  the first thing about it is that
it is plug in compatible with the list manager, i.e. all the list manager calls
are in stonetable, with a tmx_ instead of a l_ (or whatever it is), so l_new
is tmx_new.  that makes it intuitively easy as all you have to do is replace
the function names in an existing app and away you go, as the functions do
the same thing, but are much more powerful.

        i don't need to go through the list of what you can do with his
product, but i developed in weeks what would have taken me months at least
if i was using the regular list manager.  i found it all to be really easy
to use, sometimes my biggest problem was just not looking close enough at the
manual to see that he already has a function to do what i was looking at doing.

        one of the best things about it is that he is *very* responsive to
bug reports, of which there were mostly small ones.  most of the time he had
fixes within days.  i had a problem that my app was crashing, and he did
everything to help me, and eventually fixed the problem.  if half the software
companies out there gave that kind of response...

        looking back over this, it sounds like a hell of a plug, but that is
because i'm really satisfied and impressed.

        the only limitations i can think of are small things, and will
eventually be part of stone table if enough people ask for it.  no major
complaints at all.


        the look of the tables is *very* customizable, and i think very nice.
my partner thought they didn't look very mac like, but with just a few options
to the setup fuction that was taken care of.  you have a lot of freedom in
designing the looks of the tables, as well as multiple tables in windows,
moving the tables themselves, drag and drop between tables and windows, etc.
great stuff.

        if you have any specific questions, feel free to e-mail me.  i'll be
out of town the 14th - 4th.

        mickm

--

_____________________________________________________________________________
Mickey Mestel                                                [e-mail]
InfoService                                               [e-mail]
[phone]

file://ftp.netcom.com/pub/in/infoserv/inforservice.html
*we're here, excuse netcoms pathetically slow interface...

-on a beach in thailand to a beautiful, stoned, norwegian woman:
        "..yeah, it's just another foreign country without ice."
- ---------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 9 Mar 1995 15:53:33 GMT
Organization: University of Pennsylvania, Linguistics Department

In article <[e-mail]>,
Sergio Nakai <[e-mail]> wrote:
>
>I'm looking for a better and more powerful table/list manager than
>the Mac Toolbox's List Manager.  I found adds for 2 products--
>StoneTablet Publishing's Stone Table 2.0 and Graphical Business
>Interfaces, Inc.'s TableIt!  Does anybody have any comments, praises,
>concerns, etc. with either of these products or companies (quality of
>products, ease of use, look and feel of tables, support, bug fixes,
>etc)?  Or, is there a better product available?  Any help and
>information will be greatly appreciated.  Please post replies to
>the c.s.m.p.help or tools newsgroups, or email directly to
>[e-mail].  Thanks.

I can't attest to Stone Table's value, although those who use it seem to
like it.  The problem is you have to pay for it, which basically cuts me
out of the market right away since, as a starving student, I was doing good
to buy the Old IM series and a compiler to start with.  Fortunately, I've
found that it's easy to make some sturdy hacks to get the List Manager to
do what I want.

For example, when I wanted to be able to drag cells out of the window,
couldn't use LClick, since it doesn't have a hook for such a thing.  So
instead I just call the appropriate List Manager routines to figure out
which cell the mousedown fell in, then do the dragging, and then hilite the
appropriate cell with SetHilite (or whatever).  (I check to see if the
mousedown is in the scroll bar, and if so, I just call LClick and let
the List Manager do that itself).

This kind of thing really only takes a few extra lines of code, and if you
do it right it can be very sturdy.  As for myself, I'm satisfied with the
List Manager.  It can take a little ingenuity to get it to do unusual
things, but there's usually a good way to do it.  But if your time/money
ratio is better than mine, then of course it makes sense to buy something
that someone else has written and worked on until it's good and sturdy.

  \/ __ __    _\_     --Sean Crist  ([e-mail])
 ---  |  |    \ /     For a free copy of the Bill of Rights, finger
  _| ,| ,|   -----       this account.
  _| ,| ,|    [_]     Q: What do Standard Oil, AT&T, and Microsoft have in
   |  |  |    [_]        common?   A:  Nothing... yet.




+++++++++++++++++++++++++++

>From [e-mail] (Gregory D. Landweber)
Date: Thu, 09 Mar 1995 13:55:17 -0500
Organization: Harvard University

In article <3jn89t$[e-mail]>, [e-mail]
(Sean Crist) wrote:

> For example, when I wanted to be able to drag cells out of the window,
> couldn't use LClick, since it doesn't have a hook for such a thing.

Yes it does.  Just install a "lClikLoop" routine that handles drags out
of the window.  That's what I do in Greg's Browser.

-- Greg Landweber
   [e-mail]
(author of "Greg's Buttons" and "Greg's Browser")

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 9 Mar 1995 19:47:43 GMT
Organization: University of Pennsylvania, Linguistics Department

In article <[e-mail]>,
Gregory D. Landweber <[e-mail]> wrote:
>In article <3jn89t$[e-mail]>, [e-mail]
>(Sean Crist) wrote:
>
>> For example, when I wanted to be able to drag cells out of the window,
>> couldn't use LClick, since it doesn't have a hook for such a thing.
>
>Yes it does.  Just install a "lClikLoop" routine that handles drags out
>of the window.  That's what I do in Greg's Browser.

Hmpf.  You're right.  But doesn't LClick still do automatic scrolling once
the mouse is outside the list?  I wouldn't want that, but maybe the
presence of an lClikLoop tells LClick not to do automatic scrolling.  Is
that the case?

  \/ __ __    _\_     --Sean Crist  ([e-mail])
 ---  |  |    \ /     For a free copy of the Bill of Rights, finger
  _| ,| ,|   -----       this account.
  _| ,| ,|    [_]     Q: What do Standard Oil, AT&T, and Microsoft have in
   |  |  |    [_]        common?   A:  Nothing... yet.






+++++++++++++++++++++++++++

>From [e-mail] (Richard Taylor)
Date: Thu, 9 Mar 1995 21:02:56 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Sergio Nakai ([e-mail]) wrote:

: I'm looking for a better and more powerful table/list manager than
: the Mac Toolbox's List Manager.  I found adds for 2 products--
: StoneTablet Publishing's Stone Table 2.0 and Graphical Business
: Interfaces, Inc.'s TableIt!  Does anybody have any comments, praises,
: concerns, etc. with either of these products or companies (quality of

I have written many messages here praising StoneTable.  We use it in
several ways in our commercial app and we are =very= happy with it.  From
simple lists that are >32k to multiple tables in a dlog where the user
drags cells from one table to fill in another.  We also use it as a
spreadsheet and take advantage of the full font/color control even in
System 6.0.x.   I could go on and on; the support has been stupendous.

Richard Taylor

--
richard taylor:     [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Gregory D. Landweber)
Date: Thu, 09 Mar 1995 16:14:48 -0500
Organization: Harvard University

In article <3jnm0v$[e-mail]>, [e-mail]
(Sean Crist) wrote:

> In article <[e-mail]>,
> Gregory D. Landweber <[e-mail]> wrote:
> >In article <3jn89t$[e-mail]>, [e-mail]
> >(Sean Crist) wrote:
> >
> >> For example, when I wanted to be able to drag cells out of the window,
> >> couldn't use LClick, since it doesn't have a hook for such a thing.
> >
> >Yes it does.  Just install a "lClikLoop" routine that handles drags out
> >of the window.  That's what I do in Greg's Browser.
>
> Hmpf.  You're right.  But doesn't LClick still do automatic scrolling once
> the mouse is outside the list?  I wouldn't want that, but maybe the
> presence of an lClikLoop tells LClick not to do automatic scrolling.  Is
> that the case?

If the user has initiated a drag, then my lClikLoop routine retains control
until the user releases the mouse button.  So, when the user drags outside
the list, my lClikLoop routine is in control, and I don't have to worry
about LClick's automatic scrolling.

-- Greg Landweber
   [e-mail]
(author of "Greg's Buttons" and "Greg's Browser")

---------------------------

>From [e-mail] (Marty Picco)
Subject: Resources and header files
Date: Mon, 6 Mar 1995 17:07:27 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

I am a beginning mac programmer learning the toolbox et al.  I have no
problem setting up menus, etc. with ResEdit.  Is there some tool that I can
use to convert resource IDs into symbolic names (or is there some naming
convention)?  For example, when processing the result of a MenuSelect() call,
I'd prefer to use something like 'mQuit' rather than '0x800003' to refer to
my 'quit' menu item.  It seems that coding the #defines by hand would be ugly,
since there's plenty of opportunity to screw up if I use ResEdit to move
things around.

By the way, I am using CodeWarrior DR5; so far I haven't ventured into
PowerPlant.  I also don't have any apple tools except ResEdit.

Any help would be appreciated.




+++++++++++++++++++++++++++

>From Daniel Seltzer <[e-mail]>
Date: 8 Mar 1995 00:33:39 GMT
Organization: Arcus Incorporated

This is really the eternal question regarding resources as I understand
it. How to bind them to your code without the overhead of massive string
comparisons, etc. Some systems, like Visual C++ on the Windows side,
generate code for you based on the resources as you edit them. That's got
its upside, but you're dependent on specific tools and ways of working
(the MS way). Unfortunately, I still tend to rely on a large number of
constants that are defined such as:

const ResIDT Wind_MyWindow  128

I've always wished that at the least a resource editor would generate a
header file for you based on a simple template. I figure that either the
guys who make Resorcerer are working on it or it's already there and I
never stumbled on it.

__________________________________
Daniel Seltzer
Arcus Incorporated
[e-mail]

+++++++++++++++++++++++++++

>From Daniel Seltzer <[e-mail]>
Date: 8 Mar 1995 02:19:28 GMT
Organization: Arcus Incorporated

In article <3jiu13$[e-mail]> Daniel Seltzer,
[e-mail] writes:
>const ResIDT Wind_MyWindow  128

Woops. That should have read:

const ResIDT Wind_MyWindow = 128;

Too many client meetings, not enough programming: the effects are
obvious, and quite fatal.

__________________________________
Daniel Seltzer
Arcus Incorporated
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Trygve Isaacson)
Date: Thu, 9 Mar 1995 03:32:10 GMT
Organization: Freak Accident Music

In article <3jiu13$[e-mail]>, Daniel Seltzer
<[e-mail]> wrote:

> This is really the eternal question regarding resources as I understand
> it. How to bind them to your code without the overhead of massive string
> comparisons, etc. Some systems, like Visual C++ on the Windows side,
> generate code for you based on the resources as you edit them. That's got
> its upside, but you're dependent on specific tools and ways of working
> (the MS way). Unfortunately, I still tend to rely on a large number of
> constants that are defined such as:
>
> const ResIDT Wind_MyWindow  128

This may not get at what you're hoping for, but for what it's worth, here
are a couple things to remember in case you aren't taking advantage of
them:

You can use #define's for your resource IDs and put the #define's in a .h
header which is included from both your .r and .c/.h/.cp files. This lets
you keep each resource ID defined in a single place.

You can use #ifdef REZ and/or #ifndef REZ in your .h file to make both Rez
and C/C++ happy with the same file. For example, here's a .h file that can
be included by both compilers:

#define kDocumentWindowResourceID  128

#ifndef REZ

class TGeek: public TSlacker .... etc.

#endif /* REZ */

#ifdef REZ

type 'GEEK'
   {
   longint    ...etc.
   };

#endif /* REZ */

That kind of thing....
- -------------------------------------------------------------------
Trygve Isaacson                                     [e-mail]

"The sea is warship grey / it whispers "fool", then slides away" -XTC
- -------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Gregory Lo)
Date: Thu, 09 Mar 1995 20:41:23 -0500
Organization: Queen's University

If you use Rez to compile your resources from Rez source code, then
in your Rez files you can #include header files that use the same C
preprocessor #defines and stuff.

For instance, you can define the following in a file resources.h :
   #define rMyWindowAlertID 128
   #define rMenuBar 128
   #define rErrorStringsList 12545
and then #include them wherever you need in your C/C++ source code, and
also in your Rez source code.
When you define a resource in Rez, you must supply it's resource ID, so
just use the macro from the header file that you included.
You can also incorporate the resource fork of any file that has a resource
fork by using the command:
   INCLUDE 'xxx.rsrc';
where xxx.rsrc is the name of the file you want to extract the resources
from.  This is great if you want to edit the resources in ResEdit, or
what-have-you, but again, you're on your own if you want to synchronize
the resource IDs in the resource fork with the IDs used in the rest of you
r program.

- ---------------------------------------------------------
Gregory Lo  GLo ?:^(>      <mailto:[e-mail]>
<mailto:[e-mail]>      <mailto:[e-mail]>

---------------------------

>From [e-mail] (Brett M Bode)
Subject: Temporary Memory question...
Date: 20 Feb 1995 15:27:29 GMT
Organization: Iowa State University, Ames, IA (USA)

Hello,
   I am working on porting a large (4+Mb of source) application to the
PowerMac.  In this application a pool of memory is requested at run time
based on an amount read in from an input file.  Because of the way the
"dynamic" memory is addressed throughout the rest of the program (it is
obtained only once at start up) the memory must be locked such that a pointer
is used to address it.  This is of course fine if you use Malloc (or NewPtr)
to grab a portion of memory from the application partition, however, because
the amount of memory required will vary greatly from run to run this will
require the user to change the application partition size frequently.
   Thus it would seem to be better to use temporary memory for the "dynamic"
pool.  I know that the NIM Memory states that you should never leave a block
of temporary memory locked across calls to waitnextevent. Therefor my question
is: What are the ramifications of leaving temporary memory locked? What sort
of problems might occur?

Thanks for your time...

Brett Bode
[e-mail]

--
_______________________________________________________________________

Brett M Bode
201 Spedding Hall
Iowa State University
Ames, IA 50011
Phone: [phone]
[e-mail]
_______________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Sardaukar)
Date: 20 Feb 1995 21:34:23 -0500
Organization: America Online, Inc. (1-800-827-6364)

> What are the ramifications of leaving temporary memory locked? What sort
> of problems might occur?

Basically you remove the possibility of another program using temporary
memory.  If you swap to another process, the locked temp memory may
fragment the avaialable temp mem such that the next process can't do what
it needs to do.  You really shouldn't be using temp mem for so long that a
process switch is likely to occur.  Once you use it, you want to let it go
as fast as you can.  The RAM available to apps will be "shared" like this
much more in the Copland system; maybe even in the Marconi upgrade. Re
QuickDraw GX.

+++++++++++++++++++++++++++

>From [e-mail] (Tim Burrow)
Date: Tue, 21 Feb 1995 22:40:08 GMT
Organization: University of Toronto

In article <3ibjff$[e-mail]>, [e-mail]
(Sardaukar) wrote:
>In article <3iacd1$[e-mail]>, [e-mail] (Brett M
Bode) wrote:
>> What are the ramifications of leaving temporary memory locked? What sort
>> of problems might occur?
>
>Basically you remove the possibility of another program using temporary
>memory.  If you swap to another process, the locked temp memory may
>fragment the avaialable temp mem such that the next process can't do what
>it needs to do.  You really shouldn't be using temp mem for so long that a
>process switch is likely to occur.  Once you use it, you want to let it go
>as fast as you can.  The RAM available to apps will be "shared" like this
>much more in the Copland system; maybe even in the Marconi upgrade. Re
>QuickDraw GX.

I thought it was ok to use temp memory across process switches, as long as
it was not locked and belonged to a document such that closing windows
freed the memory. Thus you don't have to allocate as much memory to your
application partition as you will ever need, just a minimum amount.

Having temp memory locked when you call WaitNextEvent is a no-no.

--
Tim Burrow
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Fabrizio Oddone)
Date: Wed, 22 Feb 1995 11:00:23 +0100
Organization: Politecnico di Torino - Italy

In article <3iacd1$[e-mail]>, [e-mail] (Brett M
Bode) wrote:

[snip]
>    Thus it would seem to be better to use temporary memory for the "dynamic"
> pool.  I know that the NIM Memory states that you should never leave a block
> of temporary memory locked across calls to waitnextevent. Therefor my question
> is: What are the ramifications of leaving temporary memory locked? What sort
> of problems might occur?

I recall that you should not leave temporary memory ALLOCATED across calls
to WaitNextEvent under SYSTEM 6.
System 7 has not this requirement (you may check its availability with a
Gestalt attribute - cannot recall the exact name, ends with ...isTracked).
You can HLock the handle, but if you are reading a file into this handle,
you actually need to keep the handle locked during PBReadAsync. When
reading ends, call HUnlock.

--
 Fabrizio Oddone
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 22 Feb 1995 13:36:15 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <[e-mail]>,
Tim Burrow <[e-mail]> wrote:

>Having temp memory locked when you call WaitNextEvent is a no-no.

I don't think it is. First, it works just fine. Second, I prefer
my app to have a 384k partition and a locked 100k temporary handle,
rather than a 1024k partition "just in case".

--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/index.html ...

+++++++++++++++++++++++++++

>From [e-mail] (Brett M Bode)
Date: 22 Feb 1995 17:59:24 GMT
Organization: Iowa State University, Ames, IA (USA)

>In article <[e-mail]>,
>Tim Burrow <[e-mail]> wrote:
>
>>Having temp memory locked when you call WaitNextEvent is a no-no.
>
>I don't think it is. First, it works just fine. Second, I prefer
>my app to have a 384k partition and a locked 100k temporary handle,
>rather than a 1024k partition "just in case".
>
>--
>Francois Pottier                                            [e-mail]
>------------------------------------------------------------------------------
>Check my WWW page at http://acacia.ens.fr:8080/home/pottier/index.html ...

I have to agree with Francios. Since no one provided me with a compelling
reason (like it WILL cause crashes etc) not to try it, I went ahead and
did it and thus far I have not had a problem.  I do not think I would do
it in all cercumstances, but for my problem it seems to be fine.  For those
who didn't catch my original post what I wanted to do was grab a large
chunk of temporary memory once at launch and then lock it in place
for the duration of the run (at which point the application will terminate).
So instead of having a large application partition (which I would have to
resize depending on the particular run) I can just set the application partition
to the size needed for code and Global data and then get only as much extra
"dynamic" memory as is needed for the current run.  Just for your information
the size needed for the code and global data is about 3Mb and the dynamic
pool (depending on the run type) ranges from 1Mb to as much as you can give it
(meaning it can use 100+ Mb or more easily).

Thus I believe that doing this is not causing a problem with memory
fragmentation since I am only getting one block of memory once.  It is
probably not a good idea to repeatedly get small blocks and keep them locked,
since this would certainly lead to memory fragmentation. Also note that I
said I was doing this on PowerMacs only, thus I am using System 7.1.2 or later
so I can count on Temporary Memory being real and tracked.

Brett Bode

--
_______________________________________________________________________

Brett M Bode
201 Spedding Hall
Iowa State University
Ames, IA 50011
Phone: [phone]
[e-mail]
_______________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Wed, 22 Feb 1995 19:55:09 GMT
Organization: ISIS International

[e-mail] (Tim Burrow) writes:

>I thought it was ok to use temp memory across process switches, as long as
>it was not locked and belonged to a document such that closing windows
>freed the memory. Thus you don't have to allocate as much memory to your
>application partition as you will ever need, just a minimum amount.

My strategy when I allocate huge blocks of memory is to try first in my own
heap, and then use temp memory if that fails.

--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20
Home Page: ftp://ftp.netcom.com/pub/is/isis/home.html
PUSH THE BUTTON, FRANK... OR SOMEONE?

+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 22 Feb 1995 22:50:55 -0500
Organization: Delphi Internet Services Corporation

[e-mail] (Brett M Bode) writes:

>>In article <[e-mail]>,
>>Tim Burrow <[e-mail]> wrote:
>>
>>>Having temp memory locked when you call WaitNextEvent is a no-no.
>>
>>I don't think it is. First, it works just fine. Second, I prefer
>>my app to have a 384k partition and a locked 100k temporary handle,
>>rather than a 1024k partition "just in case".
>>
>>--
>>Francois Pottier                                            [e-mail]
>>------------------------------------------------------------------------------
>>Check my WWW page at http://acacia.ens.fr:8080/home/pottier/index.html ...

>I have to agree with Francios. Since no one provided me with a compelling
>reason (like it WILL cause crashes etc) not to try it, I went ahead and
>did it and thus far I have not had a problem.  I do not think I would do
>it in all cercumstances, but for my problem it seems to be fine.  For those
>who didn't catch my original post what I wanted to do was grab a large
>chunk of temporary memory once at launch and then lock it in place
>for the duration of the run (at which point the application will terminate).
>So instead of having a large application partition (which I would have to
>resize depending on the particular run) I can just set the application partition
>to the size needed for code and Global data and then get only as much extra
>"dynamic" memory as is needed for the current run.  Just for your information
>the size needed for the code and global data is about 3Mb and the dynamic
>pool (depending on the run type) ranges from 1Mb to as much as you can give it
>(meaning it can use 100+ Mb or more easily).

>Thus I believe that doing this is not causing a problem with memory
>fragmentation since I am only getting one block of memory once.  It is
>probably not a good idea to repeatedly get small blocks and keep them locked,
>since this would certainly lead to memory fragmentation. Also note that I
>said I was doing this on PowerMacs only, thus I am using System 7.1.2 or later
>so I can count on Temporary Memory being real and tracked.

I have to disagree.

1.  You're ignoring one of the most important Mac Tech Notes in
existence: Toolbox Karma.  Apple tells you not to leave handles locked
across calls to WNE- this means, in part, that Apple reserves the right
to break your code in the future.  Apple could easily make a change
which would break your code, and would do so without reservation,
knowing that all good developers follow the guidelines presented in
Inside Macintosh, and you are a good developer, right?

2.  IM does not tell you where the temporary memory is coming from.
So your app is 3 megabytes.  Say that you're running on a 40-meg
PowerMac.  The user has been up all night doing things with other
programs, many of which are still in memory.  The user launches your
program, which fits neatly into a space just above PageMaker and just
below Photoshop.  What he doesn't know is that you've allocated
another 2 megabytes of temporary memory.  The system had to grab this
memory from a place higher up in memory, (your app is surrounded on
either side by PS and PM, remember).  Your app locks it merrily,
happily going about it's business.  The user quits two applications
which happen to be on either side of the space in which your 2 meg
tempmem block exists, with the intent of running some application with
even larger RAM requirements than yours.  When he does this, the
system informs him that there's not enough *contiguous* free space, even
though there *is* enough *total* free space.  Do you see the point I'm
trying to make?

3.  System 7 is a reasonable minimum assumption for 68k Macs as well.

________________.______.._____...___....._.....................
Chris Thomas, [e-mail], code elf


+++++++++++++++++++++++++++

>From [e-mail] (Dave Evans)
Date: 23 Feb 1995 10:00:28 GMT
Organization: Apple Computer, Inc.

[e-mail] (Brett M Bode) wrote:
>...I know that the NIM Memory states that you should never leave a block
> of temporary memory locked across calls to waitnextevent. Therefor my question
> is: What are the ramifications of leaving temporary memory locked? What sort
> of problems might occur?

Locking temporary memory across a waitnextevent call is impolite.
Doing so may prevent memory from moving for a new application to launch.
This will cause user confusion ("but I do have that much RAM free...
why can't I launch this other application?") when your locked temporary
memory fragments the process manager's heap.  Such a fragmentation may
prevent a new application from launching if a large enough contiguous
block of this memory cannot be had.

But you can certainly do this technically.  Locking the memory across
waitnextevent should behave safely without side effects.

dave

- -
Apple Computer, Inc. pays the bills but doesn't endorse what I might
say (especially after midnight...)

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 23 Feb 1995 16:11:18 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <3ih0mv$[e-mail]>,
[e-mail] <[e-mail]> wrote:

>existence: Toolbox Karma.  Apple tells you not to leave handles locked
>across calls to WNE- this means, in part, that Apple reserves the right
>to break your code in the future.

The whole partition concept is brain-dead and is a leftover from the
old days. I'm ready to bet that it is going to disappear at some point
when the new systems arrive.

>even larger RAM requirements than yours.  When he does this, the
>system informs him that there's not enough *contiguous* free space, even
>though there *is* enough *total* free space.  Do you see the point I'm
>trying to make?

Sure. But say my app needs anywhere between 1 and 10 megs, depending on
what phase of its job it's currently doing. There are two methods, using
a big partition and using temp mem. If I ask for a 10 meg partition,
I won't create fragmentation but half of the time I'll be wasting 5 megs.
If I use temporary memory, I might add one block to the heap but the free
memory figure is much higher. I still think using temp mem is better.

What we really need is a good implementation where all apps draw their storage
from a common pool and the MMU is used to hide fragmentation, IMHO.




--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/index.html ...

+++++++++++++++++++++++++++

>From [e-mail] (Ken Prehoda)
Date: Thu, 23 Feb 1995 11:19:56 -0600
Organization: Univ of Wisc-Madison, Dept of Biochemistry

In article <3iic36$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

: In article <3ih0mv$[e-mail]>,
: [e-mail] <[e-mail]> wrote:
:
: >existence: Toolbox Karma.  Apple tells you not to leave handles locked
: >across calls to WNE- this means, in part, that Apple reserves the right
: >to break your code in the future.
:
: The whole partition concept is brain-dead and is a leftover from the
: old days. I'm ready to bet that it is going to disappear at some point
: when the new systems arrive.
:
: >even larger RAM requirements than yours.  When he does this, the
: >system informs him that there's not enough *contiguous* free space, even
: >though there *is* enough *total* free space.  Do you see the point I'm
: >trying to make?
:
: Sure. But say my app needs anywhere between 1 and 10 megs, depending on
: what phase of its job it's currently doing. There are two methods, using
: a big partition and using temp mem. If I ask for a 10 meg partition,
: I won't create fragmentation but half of the time I'll be wasting 5 megs.
: If I use temporary memory, I might add one block to the heap but the free
: memory figure is much higher. I still think using temp mem is better.
:
: What we really need is a good implementation where all apps draw their storage
: from a common pool and the MMU is used to hide fragmentation, IMHO.

And doesn't RamDoubler do a good job at this anyway?

--
Ken Prehoda, [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 23 Feb 1995 19:07:52 GMT
Organization: Primenet

Dave Evans ([e-mail]) wrote:
: [e-mail] (Brett M Bode) wrote:
: >...I know that the NIM Memory states that you should never leave a block
: > of temporary memory locked across calls to waitnextevent. Therefor my question
: > is: What are the ramifications of leaving temporary memory locked? What sort
: > of problems might occur?

: Locking temporary memory across a waitnextevent call is impolite.
: Doing so may prevent memory from moving for a new application to launch.
: This will cause user confusion ("but I do have that much RAM free...
: why can't I launch this other application?") when your locked temporary
: memory fragments the process manager's heap.  Such a fragmentation may
: prevent a new application from launching if a large enough contiguous
: block of this memory cannot be had.

: But you can certainly do this technically.  Locking the memory across
: waitnextevent should behave safely without side effects.

New IM: Memory even says this. "In certain circumstances, however, you
can hold temporary memory indefinitely. For example, if the temporary
memory is used for open files, and the user can free that memory simply
by clsing those files, it is safe to hold onto that memory as long as
necessary." (NIM:Memory, p 2-10).

Since NIM:Memory provides the gestalt selectors to determine if System 7
is being used and that the behavior for the Memory Manager is as is
described in the book, unless there is a tech note published after the
book was released, I don't see why anyone is arguing in the first place.

In otherwords, New Inside Macintosh supercedes any previously published
tech notes, and the information should apply (barring non-documented
bugs) until a new version of the book, or a new tech note is published,
as long as you are running System 7 and are checking the gestalt selector
for the proper behavior documented in the book... And NIM:Memory says
that you can hold temporary memory as long as you like, as long as you
follow the guidelines in the book.

: dave

: ---
: Apple Computer, Inc. pays the bills but doesn't endorse what I might
: say (especially after midnight...)

--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 23 Feb 1995 22:47:49 -0500
Organization: Delphi Internet Services Corporation

[e-mail] (Ken Prehoda) writes:

>In article <3iic36$[e-mail]>, [e-mail] (Francois
>Pottier) wrote:
>:
>: What we really need is a good implementation where all apps draw their storage
>: from a common pool and the MMU is used to hide fragmentation, IMHO.

>And doesn't RamDoubler do a good job at this anyway?

No.  RamDoubler just compresses RAM.  You're thinking of OptiMem
(aka OptimMem RamCharger).  Both of these can be used together if you
have the latest versions, which is rather cool, except that PowerMac
CodeWarrior users probably don't want to deal with the headaches.

It's not the same as having it integrated into the system as a
documented facility.  The problem is that many apps don't just allocate
when they need it- they implement their own memory managers, taking
their entire heap as a single block.  This is one thing Apple might be
having a hard time with in Copland.

OptiMem seems to be the best that can be done using today's apps,
though.  Don't think it uses the MMU.

________________.______.._____...___....._.....................
Chris Thomas, [e-mail], call me lightning

+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 23 Feb 1995 22:51:38 -0500
Organization: Delphi Internet Services Corporation

[e-mail] (Francois Pottier) writes:

>In article <3ih0mv$[e-mail]>,
>[e-mail] <[e-mail]> wrote:

>>existence: Toolbox Karma.  Apple tells you not to leave handles locked
>>across calls to WNE- this means, in part, that Apple reserves the right
>>to break your code in the future.

>The whole partition concept is brain-dead and is a leftover from the
>old days. I'm ready to bet that it is going to disappear at some point
>when the new systems arrive.

I agree, but what I said still applies.

>>even larger RAM requirements than yours.  When he does this, the
>>system informs him that there's not enough *contiguous* free space, even
>>though there *is* enough *total* free space.  Do you see the point I'm
>>trying to make?

>Sure. But say my app needs anywhere between 1 and 10 megs, depending on
>what phase of its job it's currently doing. There are two methods, using
>a big partition and using temp mem. If I ask for a 10 meg partition,
>I won't create fragmentation but half of the time I'll be wasting 5 megs.
>If I use temporary memory, I might add one block to the heap but the free
>memory figure is much higher. I still think using temp mem is better.

No, you missed the point, (but I didn't state it very clearly): the
average *end user*, Joe Hasntgotaclue, is not going to realize what the
problem is.  He might assume that his Mac is broken, or he might come
away thinking that MacOS sucks.  At least when you're wasting 5
megabytes, the user can find a cause for out-of-memory - your app is
wasting 10 megabytes!

>What we really need is a good implementation where all apps draw their storage
>from a common pool and the MMU is used to hide fragmentation, IMHO.

True.

________________.______.._____...___....._.....................
Chris Thomas, [e-mail], the frequency

+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 23 Feb 1995 22:56:10 -0500
Organization: Delphi Internet Services Corporation

[e-mail] (Lawson English) writes:

>Dave Evans ([e-mail]) wrote:

>: Locking temporary memory across a waitnextevent call is impolite.
>: Doing so may prevent memory from moving for a new application to launch.
>: This will cause user confusion ("but I do have that much RAM free...
>: why can't I launch this other application?") when your locked temporary
>: memory fragments the process manager's heap.  Such a fragmentation may
>: prevent a new application from launching if a large enough contiguous
>: block of this memory cannot be had.

>: But you can certainly do this technically.  Locking the memory across
>: waitnextevent should behave safely without side effects.

>New IM: Memory even says this. "In certain circumstances, however, you
>can hold temporary memory indefinitely. For example, if the temporary
>memory is used for open files, and the user can free that memory simply
>by clsing those files, it is safe to hold onto that memory as long as
>necessary." (NIM:Memory, p 2-10).

What NIM is saying is that you're allowed to keep temporary memory
through calls to WaitNextEvent.  What we're discussing is locking that
memory across calls to WaitNextEvent, which is documented as a Bad
Thing.

________________.______.._____...___....._.....................
Chris Thomas, [e-mail], really just out of habit


+++++++++++++++++++++++++++

>From [e-mail] (Ken Prehoda)
Date: Fri, 24 Feb 1995 09:27:58 -0600
Organization: Univ of Wisc-Madison, Dept of Biochemistry

In article <3ijkt5$[e-mail]>, [e-mail]
([e-mail]) wrote:

: [e-mail] (Ken Prehoda) writes:
:
: >In article <3iic36$[e-mail]>, [e-mail] (Francois
: >Pottier) wrote:
: >:
: >: What we really need is a good implementation where all apps draw
their storage
: >: from a common pool and the MMU is used to hide fragmentation, IMHO.
:
: >And doesn't RamDoubler do a good job at this anyway?
:
: No.  RamDoubler just compresses RAM.  You're thinking of OptiMem

That's not true from what I've read.  RamDoubler does not compress RAM.
What it does do is use the unused memory in an apps partition to give to
other apps (using the MMU?).  Once this memory is used up, RamDoubler
resorts to paging.

However, I have not looked into it in detail.  Do you have some other
information?

--
Ken Prehoda, [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 24 Feb 1995 22:45:03 GMT
Organization: Primenet

Ken Prehoda ([e-mail]) wrote:

: That's not true from what I've read.  RamDoubler does not compress RAM.
: What it does do is use the unused memory in an apps partition to give to
: other apps (using the MMU?).  Once this memory is used up, RamDoubler
: resorts to paging.

: However, I have not looked into it in detail.  Do you have some other
: information?

As I recall, RamDoubler does three things:

First, it pools all the unused RAM in every app's partition to free up
RAM for all partitions. When it runs low, it starts compressing RAM,
presumably using an efficient algorithm (patented, I believe). When all else
fails, it starts paging to disk.


: --
: Ken Prehoda, [e-mail]

--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Sun, 26 Feb 1995 20:27:25 GMT
Organization: ISIS International

[e-mail] (Francois Pottier) writes:

>In article <[e-mail]>,
>Tim Burrow <[e-mail]> wrote:

>>Having temp memory locked when you call WaitNextEvent is a no-no.

>I don't think it is. First, it works just fine. Second, I prefer
>my app to have a 384k partition and a locked 100k temporary handle,
>rather than a 1024k partition "just in case".

In one case I allocate a huge (4M or so) handle to use to generate an entire
300dpi page image for printing. I first try to allocate it in my own heap, and
if that fails I go to temporary memory. This seems to be a pretty good strategy
that I've done in several cases where I need a large block of memory for one
specific operation.

--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20
Home Page: ftp://ftp.netcom.com/pub/is/isis/home.html
PUSH THE BUTTON, FRANK... OR SOMEONE?

+++++++++++++++++++++++++++

>From [e-mail] (Keith Rollin)
Date: Sun, 26 Feb 1995 15:48:31 -0800
Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows?

In article <3ifekf$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

>In article <[e-mail]>,
>Tim Burrow <[e-mail]> wrote:
>
>>Having temp memory locked when you call WaitNextEvent is a no-no.
>
>I don't think it is. First, it works just fine. Second, I prefer
>my app to have a 384k partition and a locked 100k temporary handle,
>rather than a 1024k partition "just in case".

Unless you're doing something like allocating WindowRecords from this 100K
temporary memory handle, I can't think of any reason for you to keep that
handle locked across calls that could perform a context switch. Be a good
citizen and keep that handle unlocked.

- --------------------------------------------------------------------------
Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton
"I say, let's write "wacko" on all the rocks and be done with it."

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 27 Feb 1995 20:07:02 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <[e-mail]>,
Keith Rollin <[e-mail]> wrote:

>Unless you're doing something like allocating WindowRecords from this 100K
>temporary memory handle, I can't think of any reason for you to keep that
>handle locked across calls that could perform a context switch. Be a good
>citizen and keep that handle unlocked.

I can't - my handle is actually chock full of C++ pointer-based objects.
The idea is that usually I will allocate them from my own heap, but if the
user is very active and creates lots of windows, then I'll overflow into
the temporary heap. It shouldn't last very long.

Crashing is bad and gracefully exiting when new() returns nil is difficult.
This is a sad world :-/


--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/index.html ...

+++++++++++++++++++++++++++

>From [e-mail] (Stefan Kurth)
Date: Tue, 28 Feb 1995 00:29:51 +0100
Organization: none

Keith Rollin <[e-mail]> wrote:

> Unless you're doing something like allocating WindowRecords from this 100K
> temporary memory handle, I can't think of any reason for you to keep that
> handle locked across calls that could perform a context switch. Be a good
> citizen and keep that handle unlocked.

One such reason is when you want to read or write the handle's contents
to/from disk asynchronously, and (trying to be a good citizen) call
WaitNextEvent every couple of ticks meanwhile.

Now which is better, locking the handle for this relatively short period
of time, or doing the IO synchronously?  I'm asking seriously, I really
don't know.

________________________________________________________________________
Stefan Kurth               Berlin, Germany           [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Fabrizio Oddone)
Date: Thu, 02 Mar 1995 19:56:32 +0100
Organization: Politecnico di Torino - Italy

In article <3itnak$[e-mail]>, [e-mail] (Stefan
Kurth) wrote:

> Keith Rollin <[e-mail]> wrote:
>
> > Unless you're doing something like allocating WindowRecords from this 100K
> > temporary memory handle, I can't think of any reason for you to keep that
> > handle locked across calls that could perform a context switch. Be a good
> > citizen and keep that handle unlocked.
>
> One such reason is when you want to read or write the handle's contents
> to/from disk asynchronously, and (trying to be a good citizen) call
> WaitNextEvent every couple of ticks meanwhile.
>
> Now which is better, locking the handle for this relatively short period
> of time, or doing the IO synchronously?  I'm asking seriously, I really
> don't know.

If the read/write is not very time-consuming, I usually PBxxxAsync(), do
anything I can do in the meantime, then poll ioResult in a while {} loop
calling SystemTask() and EventAvail(), so I don't have to handle events
immediately; events are left in the queue and extracted later in my main
event loop.

I think async calls are generally a Good Thing, although sync calls are
easier to implement.

--
 Fabrizio Oddone
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Stefan Kurth)
Date: Fri, 03 Mar 1995 18:15:00 +0100
Organization: none

Fabrizio Oddone <[e-mail]> wrote:

> > One such reason is when you want to read or write the handle's contents
> > to/from disk asynchronously, and (trying to be a good citizen) call
> > WaitNextEvent every couple of ticks meanwhile.
> >
> > Now which is better, locking the handle for this relatively short period
> > of time, or doing the IO synchronously?  I'm asking seriously, I really
> > don't know.
>
> If the read/write is not very time-consuming, I usually PBxxxAsync(), do
> anything I can do in the meantime, then poll ioResult in a while {} loop
> calling SystemTask() and EventAvail(), so I don't have to handle events
> immediately; events are left in the queue and extracted later in my main
> event loop.

This doesn't answer the question.  If you call SystemTask and EventAvail
while waiting for your async call to complete, you have to lock the
handle, since these calls can move memory.

Anyone else?  Is it ok to lock a temp handle during an async read/write
call in order to be able to give time to other processes, or is it
better to do it synchronously instead?

________________________________________________________________________
Stefan Kurth               Berlin, Germany           [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Fri, 03 Mar 1995 15:36:53 -0500
Organization: Tulip Software

In article <3j7ire$[e-mail]>, [e-mail] (Stefan
Kurth) wrote:

> This doesn't answer the question.  If you call SystemTask and EventAvail
> while waiting for your async call to complete, you have to lock the
> handle, since these calls can move memory.
>
> Anyone else?  Is it ok to lock a temp handle during an async read/write
> call in order to be able to give time to other processes, or is it
> better to do it synchronously instead?

Locking a handle in temp memory will usually be ok. However, there are
some risks associated with it.

A lot depends on where the handle lies in the temp memory. It could
fragment the memory, thus preventing an application from launching. If it
is at the low end of temp memory, it could interfere with loading
components (e.g., QuickTime, AppleScript, etc.).

Apart from these risks, I see nothing wrong with it. And if you expect the
asynchronous I/O to complete very quickly, the risk is small and it might
be worth the risk if you get a substantial performance improvement. You
have to evaluate that.

- --------------------
Ed Anson            MediaTree: multimedia outline editor & catalog
Tulip Software
Andover, MA 01810   For details, check out my WWW page:
U.S.A.              <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (Fabrizio Oddone)
Date: Tue, 07 Mar 1995 15:20:11 +0100
Organization: Politecnico di Torino - Italy

In article <3j7ire$[e-mail]>, [e-mail] (Stefan
Kurth) wrote:

> Fabrizio Oddone <[e-mail]> wrote:
> > If the read/write is not very time-consuming, I usually PBxxxAsync(), do
> > anything I can do in the meantime, then poll ioResult in a while {} loop
> > calling SystemTask() and EventAvail(), so I don't have to handle events
> > immediately; events are left in the queue and extracted later in my main
> > event loop.
>
> This doesn't answer the question.  If you call SystemTask and EventAvail
> while waiting for your async call to complete, you have to lock the
> handle, since these calls can move memory.

Yes, you MUST obviously lock the handle.

The external fragmentation problem is a Mac OS problem, is not a Mac
developer problem (IMHO).
As soon as we see the new OS with separate address spaces, that won't be a
problem any more.

--
 Fabrizio Oddone
[e-mail]

---------------------------

>From [e-mail] (Greg Branche)
Subject: The State of MPW
Date: Mon, 06 Mar 1995 14:12:02 -0800
Organization: Apple Computer, Inc.

Gary asked me to post this a while ago, and I apologize for taking so long
to get it out.  It's been buried in my queue for at least 3 or 4 weeks,
and it's taken me this long to clear my interrupt stack to get to it.

The original thread appeared in comp.sys.mac.programmer.codewarrior, but I
felt that this reply didn't really belong there, since it primarily
concerns MPW.

Here goes:

======================================================================

In a recent message in comp.sys.mac.programmer.codewarrior, Amanda Walker
of InterCon Systems Corporation said:

 >According to the people at Apple I've spoken to, MPW will cease to exist after
 >ETO 18, and even now only has one person working part time on it, doing only
 >emergency bug fixes.

 >We've gotten official reponses from MacDTS that the Projector bugs we
 >reported last year will never be fixed, and that Apple has committed to
 >Symantec C++ as their future baseline development environment.

As the MPW product manager, allow me to set the record straight  MPW
lives on! We9ve still have plenty of engineers on the MPW team and we9re
currently looking
for more. Have a look at the last couple of MPW/E.T.O. releases to see
what they9ve been up to  native MPW tools; faster compilers; new tools to
support the CFM-68K runtime; improvements to MacApp; new debuggers; and so
on.

There may be some confusion because we are currently transitioning from
the MPW 68K C and C++ compilers to MPW-hosted C and C++ compilers that
Symantec is creating for us pursuant to a development contract. Our plan
is to roll these into 3Latest MPW2 around the E.T.O. #18 time frame, thus
obsoleting MPW C and MPW C++ (CFront). We9re doing this because it was
much easier to adapt Symantec9s compilers for use with CFM-68K (and,
therefore, OpenDoc); they provide faster turnaround times; and they
generate comparable code.

On the Power Macintosh side, we9re transitioning from PPCC to MrC,
primarily because of the much faster compile times provided by the MrC
front end (provided  by Symantec). (MrC and PPCC share the same back-end,
so code quality is the same.) The MrC compiler operates up to four times
faster than the native version of PPCC.

MPW users have told us for some time that we must improve turnaround time,
so that9s what we9ve been focusing on for some time now.

As for bug fixes, we continue to evaluate, prioritize, and fix bugs for
MPW. I9m not sure which bugs Amanda was told would 3never be fixed2;
perhaps she could tell me directly so we can learn why that response may
have been communicated. Quite often the bug list contains many enhancement
requests which may receive a low priority or be rejected for a variety of
reasons.

By the way, E.T.O. #16 and MPW Pro #16 just shipped. There are dozens of
enhancements, include a beta of MrC/MrCpp, a faster PPCLink, Native PPCAsm
1.1, MPW p2c (an Object Pascal to C/C++ source code converter), and the
CFM-68K and SOM runtimes (and related tools).

 Gary Little
 MPW Product Manager
======================================================================

Greg Branche
MPW Entomologist
Apple Computer, Inc.

---------------------------

>From [e-mail] (Daniel Van Den Broeck)
Subject: [Q] FSSpec --> dirID
Date: 16 Feb 95 09:40:51 CET
Organization: NightBreed


How can I get the dirID of a directory from wich i've got the FSSpec's ?
The FSSpec only contain the *parent* directory ID as I remember well.

Daniel Van Den Broeck
[e-mail]
2:292/603.81

+++++++++++++++++++++++++++

>From [e-mail] (Richard Wesley)
Date: 20 Feb 1995 05:29:21 GMT
Organization: Punch Deck Consulting

In article <[e-mail]>
[e-mail] (Daniel Van Den Broeck) writes:

>
> How can I get the dirID of a directory from wich i've got the FSSpec's ?
> The FSSpec only contain the *parent* directory ID as I remember well.
>
> Daniel Van Den Broeck
> [e-mail]
> 2:292/603.81

Use PBGetCatInfo.

- rmgw

- ------------------------------------------------------------------------------

Richard Wesley     [e-mail] | "If we're not careful, we could have
Punch Deck Consulting  [e-mail] |  a farce on our hands!"
     Macintosh Software Development     |    - Tom Stoppard, "On the Razzle"
- ------------------------------------------------------------------------------


+++++++++++++++++++++++++++

>From [e-mail] (David Walton)
Date: Thu, 02 Mar 1995 18:15:38 -0500
Organization: University of Notre Dame, OUC

In article <3i99bh$[e-mail]>, [e-mail] (Richard
Wesley) wrote:

> In article <[e-mail]>
> [e-mail] (Daniel Van Den Broeck) writes:
>
> >
> > How can I get the dirID of a directory from wich i've got the FSSpec's ?
> > The FSSpec only contain the *parent* directory ID as I remember well.
> >
> > Daniel Van Den Broeck
> > [e-mail]
> > 2:292/603.81
>
> Use PBGetCatInfo.
>

I just fill in the vRefNum and parID field, concatenate a fake file name
to the end of the directory name, and call FSMakeFSSpec().  Since
FSMakeFSSpec() will create a valid spec even for a non-existent file, you
can use that fact to get a valid dirID.  E.g.:

vRefNum:          -1
parID:            4315
fName (dirName):  "Untitled folder"

so:

error = FSMakeFSSpec(-1, 4315, "\pUntitled folder:fakeFile", &mySpec);
myDirID = spec.parID;/* dirID of "Untitled folder" */

David

--
David Walton
Office of University Computing/Dept. History & Philosophy of Science
University of Notre Dame
Mail:  [e-mail]           http://www.nd.edu/~dwalton1/

           "You're mighty brave in cyberspace, flame-boy."

+++++++++++++++++++++++++++

>From [e-mail] (Peter Lewis)
Date: Sat, 04 Mar 1995 09:34:39 +0800
Organization: iiNET Technologies

In article <[e-mail]>,
[e-mail] (David Walton) wrote:

>I just fill in the vRefNum and parID field, concatenate a fake file name
>to the end of the directory name, and call FSMakeFSSpec().  Since
>FSMakeFSSpec() will create a valid spec even for a non-existent file, you
>can use that fact to get a valid dirID.  E.g.:
>
>vRefNum:          -1
>parID:            4315
>fName (dirName):  "Untitled folder"

That will work

>error = FSMakeFSSpec(-1, 4315, "\pUntitled folder:fakeFile", &mySpec);
>myDirID = spec.parID;/* dirID of "Untitled folder" */

Untitled folder:fakeFile is a full path name, so I expect it will ignore
the 4315 dirID and return an invalid FSSpec.  I use FSpGetCatInfo - which
of course isn't implemented by the OS, but it is a very useful routine to
have in your collection:

   function FSpGetCatInfo (var fs: FSSpec; index: integer; var pb:
CInfoPBRec): OSErr;
   begin
      pb.ioVRefNum := fs.vRefNum;
      pb.ioDirID := fs.parID;
      pb.ioNamePtr := @fs.name;
      pb.ioFDirIndex := index;
      FSpGetCatInfo := PBGetCatInfoSync(@pb);
   end;

or it's companion HGetCatInfo:

   function HGetCatInfo (vrn: integer; dirID: longInt; var name: string;
index: integer; var pb: CInfoPBRec): OSErr;
   begin
      pb.ioVRefNum := vrn;
      pb.ioDirID := dirID;
      pb.ioNamePtr := @name;
      pb.ioFDirIndex := index;
      HGetCatInfo := PBGetCatInfoSync(@pb);
   end;

So you would do:

err := HGetCatInfo(-1,4315,"Untitled folder",-1,pb);
dirID:=pb.ioDirID;

or
err := FSpGetCatInfo(fs,-1,pb);
fs.parID:=pb.ioDirID;
fs.name:='';

Enjoy,
   Peter.
--
The probability of me making it to the WWDC in 1995 is currently: 95%

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Michael Vail)
Date: Sun, 05 Mar 1995 22:09:48 -0500
Organization: Vailhalla

In article <[e-mail]>,
[e-mail] (Peter Lewis) wrote:

:In article <[e-mail]>,
:[e-mail] (David Walton) wrote:
:
:>I just fill in the vRefNum and parID field, concatenate a fake file name
:>to the end of the directory name, and call FSMakeFSSpec().  Since
:>FSMakeFSSpec() will create a valid spec even for a non-existent file, you
:>can use that fact to get a valid dirID.  E.g.:
:>
:>vRefNum:          -1
:>parID:            4315
:>fName (dirName):  "Untitled folder"
:
:That will work
:
:>error = FSMakeFSSpec(-1, 4315, "\pUntitled folder:fakeFile", &mySpec);
:>myDirID = spec.parID;/* dirID of "Untitled folder" */
:
:Untitled folder:fakeFile is a full path name, so I expect it will ignore
:the 4315 dirID and return an invalid FSSpec.

True, but if you put a colon in front of it as well ("\p:Untitled
folder:fakeFile"), it will work.

And probably everybody in the world knew this but me, but I just found out
that if you have an FSSpec to a file and you want one for the parent of
that file, you can use (assume fileSpec is the FSSpec of the file you
have, and you want the parent spec in parentSpec):

   FSMakeFSSpec(fileSpec.vRefNum, fileSpec.parID, "\p:", &parentSpec);

Kevin
--
Kevin Michael Vail              |  As a general rule, don't solve puzzles
[e-mail]  |  that open portals to Hell.
                                |   -- A Horror Movie Character's Survival Guide

---------------------------

End of C.S.M.P. Digest
**********************